人工智慧從單純的問答模型走向具備自主執行能力的Agent時代，靜態的資訊安全防禦模型隨時都有新的攻擊手法。過往的存取控制大多採用全有或全無的靜態權限策略，只要系統判定使用者或Agent擁有某項API的呼叫權限，該次操作就會被予以放行。

當Agent具備連續呼叫工具、自我修正與語意推理的能力時，攻擊者便能透過間接提示注入（Indirect Prompt Injection）或記憶污染（Memory Poisoning），引導Agent執行一系列單個動作合規、組合起來卻構成敏感情資外洩或非授權操作的授權內動作串接攻擊（Authorized-action chaining attack）。

為了破解這種「穿著合規外衣」的隱蔽攻擊，現代資安架構導入了能力狀態機（Capability State Machine）。本文將深度拆解能力狀態機的運作架構、數學與邏輯轉移機制，以及它如何透過「動態權限收縮」為Agent建立起無法逾越的動態安全邊界。

一、 為什麼需要能力狀態機？存取控制的困境

在軟體系統中，權限控制通常基於角色（RBAC）或屬性（ABAC）。例：辦公室助理Agent具備「讀取內部 Slack 訊息」與「發送對外 Email」兩項權限。

當Agent在執行任務時，Gatekeeper會進行如下檢查：

• 動作 A（搜尋 Slack）：檢查權限表 > 具備 slack:read 權限 > 放行
• 動作 B（發送 Email）：檢查權限表 > 具備 email:send 權限 > 放行

這種無狀態（Stateless）的靜態檢測忽略了最關鍵的一點：動作A的執行，已經改變了Agent當前上下文的敏感度與風險等級。

如果動作A讓Agent讀取到了公司內部的API金鑰，而動作B隨即將該金鑰傳送到外部郵件地址，整個過程在Gatekeeper眼中完全合規，但實際上卻已經造成了嚴重的資料洩漏。

能力狀態機正是為了打破這種無狀態的盲點而生。它的核心哲學是：權限不該是固定的，而應該隨著Agent的行為歷史與當前狀態動態演進與收縮。

二、 能力狀態機的核心架構與運作原理

能力狀態機將Agent的執行生命週期抽象化為一個有限狀態機（Finite State Machine, FSM）。狀態機由四個核心要素組成：

三層狀態轉移模型演練

為了直觀理解能力狀態機如何運作，我們可以將一個典型的辦公Agent劃分為三個核心狀態：

狀態 0：高信任/無敏狀態（High-Trust State, S0）

• 情境描述：Agent剛啟動，或僅處理一般性公開任務（如查詢天氣、總結公開新聞）
• 可用能力 C(S0)：全工具開放（包含內部資料庫讀取、外部網路搜尋、Email 發送等）

狀態 1：高敏資料隔離狀態（Sensitive-Data Isolated State, S1）

• 觸發條件：Agent執行了讀取高敏感資料的工具，如 read_slack_credentials() 或 fetch_payroll_db()
• 狀態轉移：δ(S0,read_sensitive_data) > S1
• 動態能力收縮：C(S1)
• 維持開放：內部數據分析工具、本地摘要工具
• 強制凍結：所有對外管道（如： send_email, http_post, web_upload）
• 安全邏輯：Agent一接觸了敏感資料，其身分立即轉變為高風險載體，為了防止潛在的間接提示注入將資料帶出，系統會瞬間關閉其對外輸出能力（Data Exfiltration Protection）

狀態 2：異常阻斷與隔離狀態（Quarantine State, S2）

• 觸發條件：處於 S1 狀態下的Agent試圖呼叫已遭凍結的對外工具（如 send_email）
• 狀態轉移：δ(S1,send_email) > S2
• 處置機制：中斷Agent的執行流程、拋出安全異常警報、將當前上下文送交人工審查或強制重置Agent狀態

三、 與「判別式感測器」的協同作戰：雙層防禦體系

在實際部署中，單靠預先定義好的狀態轉移規則（Hard-coded Rules），有時難以應對複雜多變的自然語言意圖。因此，能力狀態機通常會與判別式感測器（Discriminative Sensor）深度結合，構成「雙層防禦架構」。

1. 感測器負責「語意與序列判讀」：感測器持續監控Agent的歷史動作序列（Action Sequence），透過機器學習模型計算當前行為模式是否偏離正常軌跡，輸出異常機率值 P
2. 狀態機負責「實體防禦與執行」：

• 當 P 低於閾值時，狀態機維持正常轉移
• 當 P 超過閾值（即使當前動作單看是合法的），感測器會向狀態機發出警告，觸發狀態機提前將Agent的狀態推入 S1（降權狀態） 或 S2（阻斷狀態）

這種「感測器提供情報，狀態機執行管束」的協同機制，讓動態防禦既具備機器學習的彈性，又具備狀態機確定性的安全保障。

四、能力狀態機在系統落地的關鍵技術挑戰

雖然能力狀態機在理論上極具吸引力，但在將其整合至企業級Agent系統時，開發團隊必須克服以下四大工程挑戰：

1. 全中介（Full Interception）的嚴格維護

能力狀態機必須作為Agent與外部工具之間唯一的代理者（Mediator）。系統必須確保Agent無法繞過狀態機直接調用API。這通常需要搭配基於物件能力（Object-Capability）的程式庫或沙盒隔離環境（Sandbox）來實現。

2. 狀態還原與任務恢復機制（State Recovery）

如果Agent因為一時誤觸敏感資料而被推入降權狀態S1，但使用者確實需要Agent幫忙將分析好的財務報告發送給指定主管，系統該如何處理？

• 解決方案：引入人工介入授權（Human-in-the-loop, HITL）。當狀態機阻止高風險轉移時，系統彈出確認視窗，由使用者手動簽核憑證後，狀態機才安全地解除限制或一次性放行該特定動作。

3. 狀態爆炸與細粒度控制（Granularity Trade-off）

若狀態劃分過於粗糙，容易引發誤報，導致正常任務無法完成；若狀態劃分過於精細，狀態數量（|S|）將呈現指數型成長，導致轉移矩陣過於複雜、難以維護。設計者必須在業務靈活性與狀態複雜度之間取得精確平衡。

4. 上下文清洗與安全邊界維護（Context Cleansing）

若要讓Agent從高敏狀態S1安全地回到高信任狀態S0，單純將狀態變數改回S0是不夠的。系統必須同時進行上下文清洗（Context Scrubbing），清除Agent短期記憶中載入的高敏感資料，防止其在狀態切換後仍利用殘留記憶進行攻擊。

五、 結論

Capability State Machine透過將安全信任轉化為動態演進的狀態，確保Agent的每一次工具呼叫，都受當前狀態與歷史行為影響。它不僅補足了Gatekeeper機制對授權內動作串接攻擊的失明死角，更為未來無所不在的智慧代理，建構出一套兼具安全性、可預測性與實務落地價值的動態安全防線。